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Context 


►  The  client  is  producing  software-intensive,  distributed  systems  in  short 
development  cycles  (90  day  increment  spins) 

►  The  DoD  JCIDS  process  requires  the  documentation  of  systems  in  the 
form  of  certain  DODAF  products 

►  Occasionally  this  documentation  is  created  after  the  fact  and  not  as  a 
basis  for  Modeling  &  Simulation  or  software  development 

(notion:  coding  is  faster  than  architecting) 

►  Effort  spent  on  architecture  development  is  essentially  wasted,  since 
architecture  products  are  not  used  for  value-added  delivery,  and 
architecture  models  and  code  evolve  separate  from  each  other 
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Challenge 


Investigate  the  integration  of  Architecture  models  in  the  Modeling  &  Simulation 
and  Software  Design  and  Development  Process 

Develop  a  methodology  that: 

►  Identifies  those  architecture  products  that  are  relevant  for  the  design  of  software¬ 
intensive  systems 

►  Provides  guidance  as  to  the  sequence  in  which  these  models  should  be  created 

►  Provides  guidance  as  to  the  methods  that  should  be  used  when  creating  these 
models 

►  Provides  guidance  as  to  the  use  of  the  recommended  methods 
Evaluate  the  methodology  against  tool  capabilities  available  to  the  client 

►  Particular  focus  on  tool  extensions  (UPDM,  SysML,  SoaML,  BPMN) 

►  Leverage  “best  of  breed”  architecture  methodologies 
Provide  tooling  to  support  the  methodology 
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How  Good  is  a  Language? 
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Benchmarking  a  Language 


Key 

BWW 

Set  of  constructs  described  in  the  BWW 
model 

ML 

Set  of  constructs  comprising  the  Modelling 
Language 

• 

Construct  described  in  the  BWW  model 

O 

Modelling  language  construct 

Baseline  Modeling 

Ontology  Language 
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Mapping  Options 

►  Modeling  Language  (i.e.  Diagram  Type)  to  DoDAF  View 

►  Coarse-grained 

►  Good  for  initial  assessment 

►  Modeling  Language  Construct  to  DoDAF  2.0  MetaModel  Entry 

►  Fine-grained 

►  May  help  in  tailoring  language 
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DM2  Concepts 


Example:  DoDAF  2.0  Capability 
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Example:  BPMN 
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Mapping  SysML  to  DoDAF  2.0 


Understanding  JCIDS 
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Required  (PM  needs  to  check  with  their  Component  for  any  additional  architectural/regulatory  requirements  for 
CDDs,  CPDs,  ISPs/TISPs.  (e  g.,  HQDA  requires  the  SV-IOc) 


Note  1 


Required  only  when  IT  and  NSS  collects,  processes,  or  uses  any  shared  data  or  when  IT  and  NSS  exposes, 
consumes  or  implements  shared  services. 


Note  2 


The  TV-1  and  TV-2  are  built  using  the  DISRonline  and  must  be  posted  for  compliance. 


Note  3 


The  AV-1  must  be  uploaded  onto  DARS  and  must  be  registered  in  DARS  for  compliance 


Note  4 


Only  required  for  Milestone  C,  if  applicable  (see  Note  1) 


Note  5 


The  naming  of  the  architecture  views  is  expected  to  change  with  the  release  of  DODAF  v2.0  (e.g.,  StdV,  SvcV, 
StdV,  DIV).  The  requirements  of  this  matrix  will  not  change. 


Table  E-l.  XR-KPP  Products  Matrix 
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